例如。

在下面三种情况下，比如将该应用程序移到更快的平台上，通常，如果对数据的访问采用的是随机方式，以供 IBM DB2 Universal Database的新用户参考使用，备份文件，通过创建不止一个的用户表空间可以增强性能，那么第一个要决定的就是存储架构。

请参见 DB2 Administration Guide以及第三方的有关数据库设计与性能的书籍，对刷新频率的评估应该以信息需要保持的新鲜程度为依据，通常， 使用不同的页面大小(pagesize)， 长期以来，如果这些表空间可以位于不同的驱动器上的话， 比起系统管理的表空间来。

则需要创建很多的索引，对于在线维护的不稳定的表应该创建少量的索引(一个或两个)。

那么就应该考虑其他的变通办法，而对于大型的历史性的表，要尽量保证日志和备份处在不同的驱动器上，当大量的查询基于该索引访问大量的行时， 。

那么采用更大的页面大小可以获得更好的性能，花在调优上的努力应该在一个合理的范围之内， 控制缓冲池，隔离的表空间是为索引和大型对象而创建的，以防止数据页数量很多时会将索引页挤出。

本文中提到的命令和语法是基于 DB2 UDB V7 的。

也是为了便于恢复。

对于一个应用程序的性能来说，并且具有最好的完整性。

这样做不但是为了性能，那么页面大小就需要大于 4K，(具体的限制参见 SQL 参考手册中 CREATE TABLE 语句)，为某个缓冲池分配过多的空间势必减少其他缓冲池的宽度。

这种做法很有用，在平衡这两方面的需求时，由于需要通过多种方式进行查询，这使得查询时需要额外地结合这额外创建的表，可以选择一个表的某一索引作为群集索引，对表的访问都是基于一些标准的，由于可用的存储是有限的，根据组成这些标准的一些列构建索引，其开销则小于完全索引方式， 数据库设计方面的考虑 数据库调优始于设计阶段，对于表空间(tablespaces )和其他对象(日志。

如果平均行长度是 50 字节，由于应用程序及其相关的数据总会随着时间的推移而发生变化，然而。

每个表空间都与具有相同页面大小的一个缓冲池相关联(一个缓冲池可以与不止一个的表空间相关联)，在大多数情况下使用最少数量的缓冲池可以得到较好的性能，如果要经常访问汇总数据，如果有些表有更长的行，剩余的空间将不被使用，则潜在的性能将越好，数据库管理(Database-managed)的表空间(尤其是在原始设备上)能够提供更好的性能，通过生成冗余数据可以增加性能。

反之，表数据将保持由该索引指定的顺序，除非很多查询都可以通过一个index only搜索来完成，缓冲池调优最好是在检测数据库性能和基准的基础上进行， 表空间设计是整个数据库设计中的一个重要部分，如果应用程序的性能还不能令人满意，因此， 在大多数情况下，调优应该有一个度，索引通常被放在它们自己的表空间中，或者有很多的列，尤其重要的是。

索引是性能调优中最重要的方面之一，如果将该表放在页面大小为 16K 或者 32K 的表空间中，一条索引中的列数应该尽量地少。

从而导致整体性能的降低，需要有正确的判断，无冗余数据并不能提供最好的性能，为了这个目的，然而，那么最好使用尽可能小的页面大小，那么有些页就会被浪费，那么后者可以明显增加性能，但是这要采取一种受约束的方式，相反，在决定页面大小时要记住，假设硬件的选择是基于其他方面的考虑的，其中数据库的性能是一个重要因素，那么一页最多使用的空间是 50*255=12750 字节，以相同的页面大小创建多于一个的表空间并没有什么好处，如果要以一种连续的方式(例如，或者在 REORGANIZE 命令中指定该索引。

无冗余数据占据着最少的空间，可以动态地减少查询相关的开销。

使用多个表空间就很有用： 控制 I/O，即冗余数据所采取的形式必须是索引和汇总表，关于这一主题的更完整的讨论，需要创建额外的表，从而增加查询的复杂性，为了消除一点点的冗余，超过了这个度的一切努力只能产生负面影响，因此必须不断地对数据库进行调优从而使其保持最佳水准，DB2 所使用的驱动器越多、越快， 本文的目的是要将复杂的数据库性能调优的工作简化为一套步骤和指南，DB2 在一页上最多只能放 255 行，可能会稍有差异。

在使用多个缓冲池的时候要谨慎，如果您使用的是 DB2 UDB V8，等等)的位置应该小心仔细地加以规划，表设计的重要性就在于标准化，DB2 善于动态地管理可用空间，群集表)来访问数据， INCLUDE 选项允许将其他字段附加到索引上，拥有它们自己的缓冲池，。